feat(cloud): retract the stale cloud row of a superseded continuation - #701

Problem

#693 dedupes compacted continuation families locally ("only the newest sibling is listable"), but the demoted sibling's cloud row lingers until the retention window ages it out. Teammates' Team Sessions keep showing two rows for one conversation while the owner's sidebar shows one — the stale duplicate the local dedupe was built to remove.

Solution

The vanished sweep gains a second reconcile pass, with strictly positive evidence:

• A new imported_history_continuation_statuses command reports, for push-marked ids, whether the imported cache holds the row AND a strictly newer continuation sibling exists (cached_session_continuation_status_from_conn), plus the elected lineage id. Absence from the cache is "unknown", never "superseded" — a rebuilding cache cannot trigger this path, unlike absence-based evidence.
• The engine retracts such a row only when the family's listable winner is itself replay-pushed to the same org (hasReplayPushed: cursor with pushedCount > 0), under the same two-strike deferral as the vanished path, with its own audit verb: cloud retract [superseded continuation] (matched by the existing destructive-effect audit grep).
• A failed status lookup reads as unknown; generation guards and org-backoff behave like the vanished path.

Deliberate content tradeoff (please review this explicitly)

The demoted row is the only cloud replay of the pre-compact detail; the winner carries the compacted continuation. Retracting it means teammates lose replay access to that detail (the compacted summary in the winner covers the conversation). The owner's source transcript is untouched and can be re-shared at any time. If the team prefers keeping historical epochs replayable, the alternative is documenting the lingering duplicate instead — this PR takes the "one canonical row per conversation" reading of #693's intent.

Verification

• Engine tests: two-strike retract with a naturally pushed winner; no retract while the family has no pushed winner; failed lookup retracts nothing; existing vanished-sweep and session suites green (64 tests across three files).
• cargo test -p orgtrack_core --lib imported_history — 69 passed; scoped clippy clean; pnpm typecheck clean.
• Not yet run: the dual-instance real-machine cell (owner compacts a shared session → old row tombstones after two sweeps → receiver's Team Sessions shows exactly one row). Per the dual-instance-verification protocol this must pass before the change is declared verified; I can run it on the existing synthetic rig on request — flagging the uncovered cell explicitly rather than claiming it.